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Un protocole auto-stabilisant a la capacité de converger vers un comportement correct quel que soit son état initial. La 
grande majorité des travaux en auto-stabilisation supposent une communication par mémoire partagée ou bien à travers 
des canaux de communication fiables et FIFO. Dans cet article, nous nous intéressons aux systèmes auto-stabilisants à 
passage de messages à travers des canaux de capacité bornée mais non fiables et non FIFO. Nous proposons un protocole 
de communication (entre voisins) stabilisant et offrant une tolérance optimale. Plus précisément, ce protocole simule 
un canal de communication fiable et FIFO garantissant un nombre minimal de pertes, de duplications, de créations et 
de ré-ordonnancements de messages. 
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1 Motivations et Définitions 

U auto-stabilisation |Dij74| est une propriété des systèmes distribués permettant de tolérer des fautes 
transitoires (Le. de durée finie) de type arbitraire. Plus précisément, un système est dit auto-stabilisant s'il 
garantit que toute exécution issue d'une configuration arbitraire retrouve en un temps fini un comportement 
conforme à la spécification du système et ceci sans aide extérieure (humaine ou autre). 

Motivations Étant donné que F auto-stabilisation est une propriété non triviale à satisfaire, une large part 
des travaux traitant de ce domaine se placent dans un modèle de communication très simple dans lequel tous 
les processeurs peuvent déterminer de manière atomique l'état de tous leurs voisins (ce modèle de calcul 
est connu sous le nom de modèle à états). Il est cependant évident que ce modèle n'est pas réaliste et qu'un 
modèle plus classique comme le modèle asynchrone à passage de messages est plus proche d'un système 
réel. Dans un tel modèle, les processeurs voisins communiquent par envoi et réception de messages à travers 
le canal de communication qui les sépare. Il existe des transformateurs permettant de passer de manière 
automatique du premier modèle au second flPolOOl IDIM93I ainsi que des algorithmes écrits directement 
pour le modèle à passage de messages BDT06I IBKM97I1 mais ceux-ci supposent l'existence d'un protocole 
de communication entre processeurs voisins. Le protocole de communication (entre voisins) le plus connu 
est le protocole du bit alterné (PBA). Il a été prouvé que ce protocole fournit des propriétés de stabilisation 
IIAB93I IDIM93II . En effet, pour toute exécution du PBA, il existe un suffixe qui satisfait la spécification 
{Le. le PBA est pseudo-stabilisant IIBGM93I ). Après les résultats de IIGM91I IDÏM93II qui montrent qu'il 
est impossible de fournir un protocole de communication avec une mémoire bornée si les canaux sont de 
capacité non bornée, les travaux récents se sont concentrés sur des systèmes avec des canaux de capacité 
bornée. II existe différents protocoles de communication stabilisants à travers des canaux de capacité bornée 
qui différent par les hypothèses faites sur le système (mémoire bornée, canaux, etc.) mais toutes les solutions 
connues |BGM93 HN M99l[\irÔÔ]| considèrent des canaux FIFO. 

Un défaut commun à tous les protocoles de communication précédents est qu'ils ne fournissent aucune 
mesure de l'impact quantitatif des fautes transitoires sur les messages transmis. Partant d'une configuration 
initiale arbitraire, le contenu initial des canaux est lui aussi arbitraire, ce qui peut conduire le protocole à 
perdre, dupliquer des messages ou bien délivrer de faux messages (qui n'ont pas été envoyés mais résultent 
des fautes initiales). Du point de vue de l'application qui utilise le protocole de communication, il est 
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primordial de connaître des bornes sur le nombre de messages pouvant subir de tels aléas. À notre connais- 
sance, seuls BDDNTIOI IDT06II traitent de ce problème dans une certaine mesure. En effet, ils peuvent 
être adaptés pour obtenir des protocoles de communication instantanénement stabilisants. La stabilisation 
instantanée assure que tout message envoyé sera délivré en un temps fini, mais le nombre de messages 
dupliqués ou de faux messages crées n'est pas étudié. 

Contributions Notre contribution dans cet article est double. Dans un premier temps, nous définissons un 
ensemble de métriques pour mesurer la performance d'un protocole de communication stabilisant et nous 
donnons des bornes inférieures pour plusieurs d'entre elles. En particulier, nous montrons que tout protocole 
de communication stabilisant à travers des canaux de capacité bornée non fiables et non FIFO peut être 
contraint à dupliquer un message, à délivrer un faux message ou à ré-ordonner un message. Dans un second 
temps, nous proposons un protocole optimal par rapport aux bornes inférieures évoquées précèdement. 

Spécification Nous considérons ici un système distribué à passage de messages réduit à deux processeurs : 
Pi qui sera considéré comme émetteur de messages et pj qui sera considéré comme récepteur de messages. 
Le canal de communication séparant /?,- et pj est constitué de deux canaux virtuels de directions opposées. 
Le premier, (/, j), permet à pi d'envoyer des messages à pj tandis que le second, (y, /), permet à pj d'envoyer 
des acquittements à p,-. Chacun de ces canaux virtuels est asynchrone (le temps de livraison de tout message 
est fini mais non borné), a une capacité bornée de c messages (tout envoi de messages lorsque cette borne 
est atteinte conduit à la perte d'un message arbitraire), non fiable (tout message peut être perdu à un moment 
arbitraire) mais équitable (tout message envoyé infiniment souvent est reçu infiniment souvent) et non-FIFO 
(l'ordre d'arrivée des messages est indépendant de l'ordre d'envoi). Il faut noter que, en raison du contexte 
auto-stabilisant, chaque canal virtuel contient initialement jusqu'à c messages de contenu arbitraire. 

La spécification que nous présentons à présent est inspirée de celle de | |Lyn96| mais elle est adaptée au 
contexte auto-stabilisant. Supposons que nous avons une application distribuée qui souhaite envoyer des 
messages de p, à pj. Notre objectif est de fournir un protocole de communication à cette application qui 
remplit cette tâche de manière transparente malgré les caractéristiques du canal de communication. Cette 
application envoit un message lorsqu'elle demande au protocole de communication de faire parvenir un 
message depuis vers pj. Un message est délivré à pj lorsque le protocole de communication fournit ce 
message à l'application s'exécutant sur pj. Un message fantôme est un message délivré à pj alors qu'il n'a 
pas été envoyé par Un message dupliqué est un message délivré plusieurs fois à pj alors qu'il n'a été 
envoyé qu'une fois par p,. Un message perdu est un message envoyé par p, mais jamais délivré à pj. Un 
message m est ré-ordonné lorsqu'il délivré à pj avant un message m' alors que m a été envoyé après m' par 
Pi. Le but d'un protocole de communication stabilisant est alors de fournir des propriétés sur le nombre de 
messages perdus, dupliqués, fantômes et ré-ordonnés. Nous spécifions notre problème comme suit : 

Définition 1 Un protocole de communication est (a, fi, y ^b)- stabilisant sur des canaux c-bornés s'il remplit 
les conditions suivantes pour toute exécution issue d'une configuration arbitraire : 

- Dans le pire cas, seuls les a premiers messages envoyés par pi peuvent être perdus. 

- Dans le pire cas, seuls les P premiers messages délivrés à pj peuvent être des messages dupliqués. 

- Dans le pire cas, seuls les j premiers messages délivrés à pj peuvent être des messages fantômes. 

- Dans le pire cas, seuls les S premiers messages délivrés à pj peuvent être des messages ré-ordonnés. 

2 Bornes inférieures 

Étant donné que tout protocole de communication doit avoir dans son code une instruction pour délivrer 
les messages à l'application et que, dans un contexte auto-stabilisant, le compteur ordinal peut être arbitrai- 
rement corrompu dans la configuration initiale, il est possible que la première instruction exécutée par le 
processeur récepteur soit la livraison d'un message qui n' a jamais été envoyé. Le. un message fantôme. Si, 
de plus, ce message fantôme est identique à un autre message envoyé par /?,■ dans l'exécution considérée, ce 
message peut devenir un message dupliqué ou ré-ordonné. Nous obtenons les résultats suivants. 

Tliéorème 1 II n 'existe pas de protocole de communication (a, p,y, b)- stabilisant sur des canaux c-bornés 
avec p = 0, Y = OM S = 0. 
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3 Protocole de communication (0, 1, 1, l)-stabilisant 

Nous sommes maintenant en mesure de présenter notre protocole de communication. Celui-ci est com- 
posé de deux fonctions : Send(m) qui est exécutée par à chaque fois qu'il souhaite envoyer un message 
m (Send est bloquant, i.e. pi doit attendre la fin de son exécution avant de commencer à envoyer le message 
suivant) et Receive() qui est exécutée par pj en continu. 

Idée générale L'idée de base de notre protocole est de modifier le PB A de manière à améliorer ses pro- 
priétés de tolérance. Si le processeur pi souhaite envoyer un message m, il envoie celui-ci de manière 
périodique et pj acquitte chaque copie de m qu'il reçoit. Le processeur pj n'est autorisé à délivrer le mes- 
sage m que lorsqu'il en a reçu c + 1 copies (pour assurer qu'au moins l'une d'entre elles a bien été envoyée 
par Pi). De plus, m n'est délivré que si la valeur du bit alterné qui lui est associée est différente de celle du 
dernier message délivré par pj (de manière à assurer que le message ne soit pas dupliqué car /?,■ continue 
d'envoyer m tant qu'il n'a pas reçu suffisament d'acquittements). Afin d'assurer que pj a reçu au moins 
c+l copies du message, pi attend d'avoir reçu 3c + 2 acquittements avant d'arrêter d'envoyer m (en effet, 
au plus c+l acquittements sont dûs à la configuration initiale tandis que au plus c sont dûs à la présence 
initiale de messages erronnés dans le canal {i,j)). A ce stade, notre protocole ne garantit pas encore l'ab- 
sence de pertes de messages à cause de l'utilisation du bit alterné (en effet, si le bit alterné du message 
et du récepteur ne sont pas initialement synchronisés, le premier message envoyé par pi peut être perdu). 
Pour éviter cela, pi alterne entre l'envoi de messages de synchronisation et de m. Plus précisément, pour 
envoyer un message m, pi connmence par envoyer un message de synchronisation (noté < SYNCHRO >) 
jusqu'à recevoir 3c + 2 acquittements avant d'envoyer le message m lui-même jusqu'à en recevoir 3c + 2 
acquittements. Il s'ensuit que seul le message de synchronisation est perdu dans le pire des cas. 

Présentation détaillée Notre protocole est présenté en Figure 1. La procédure Send se contente d'en- 
voyer un message de synchronisation puis le message reçu en paramètre (à l'aide de la fonction auxilUaire 
SendMessage) après avoir alterné la valeur du bit associé. Finalement, elle délivre un acquittement à l'ap- 
phcation à l'aide de la fonction DeliverAck. La fonction auxilhaire SendMessage envoit périodiquement 
le message à l'aide de la fonction SendPacket (qui permet d'envoyer un paquet sur le canal {i, j)) et compte 
le nombre d'acquittement reçus en faisant appel à la fonction ReceivePacket (qui permet de récupérer un 
message dans le canal {j, i)). Celle-ci s'arrête lorsqu'elle a compté 3c + 2 acquittements. 





Send 




Receive 


entrée : m : message à envoyer 


variables : 


variable : ah : booléen donnant la valeur du bit alterné actuelle 


last jdelivered : booléen donnant la valeur du bit alterné du 


01 


ab :— -^ab 




dernier message délivré 


02 


SendMessage (< SYNCHRO >,ab) 


fi: 


file de taille c + 1 de 3-tuples (m,ab,count), où m est un message. 


03 


ab := -lab 




ab est tme valeur du bit alterné, et count est un entier donnant le 


04 


SendMessage (m,ab) 




nombre de paquets {m,ab) reçus pour m et ab depuis le dernier 


05 


DeliverAcIt (m) 

SendMessage 




DeliverMessage ou DropMessage. L'opérateur [] renvoit un 
pointeur sur le count associé à son paramètre et place ce 3-tuple 
en tête de liste 


entrée : m' : message à envoyer 


01 


upon ReceivePacItet (m, ab) 




ab : booléen donnant la valeur du bit alterné associé à m 


02 


Q[m,ab] := mm{Q[m,ab\ + \,c-\-\) 


variable : ack : entier donnant le nombre d'acquittements reçu pour 


03 


if Q[m,ab] > c + 1 then 




la valeur actuelle de ab 


04 


if lastjdelivered ^ ab then 


01 


ack := 


05 


ifm^< SYNCHRO > then 


02 


while ack< 3c + 2 


06 


DeliverMessage (m) 


03 


SendPacket (m',ab) 


07 


else 


04 


if ReceivePaclset (ack, (m',ab)) 


08 


DropMessage (m) 


05 


ack := ack + 1 ; 


09 
10 
11 


lastjîelivered := ab 
SendPacket (ack, (m,ab)) 



Figure 1: S(DL, un protocole de communication (0, 1, 1, 1) -stabilisant. 



À chaque réception de message (réalisée grâce à la fonction ReceivePacket), la procédure Receive 
incrémente le compteur associé au message qu'elle vient de recevoir. Dans le cas où le message a été 
reçu c+l fois, la file servant à stocker les messages reçus est vidée. Si, de plus, la valeur du bit alterné est 
différente de celle du demier message reçu au moins c+l fois, alors le message est soit délivré à l'appli- 
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cation à l'aide de DeliverMessage (s'il s'agit d'un message normal) ou bien détruit à l'aide de la fonction 
DropMessage (s'il s'agit d'un message de synchronisation qui est donc sans intérêt pour l'application). 
Dans les deux cas, le bit du récepteur est alterné. Tout message reçu est acquitté (à l'aide de la fonction 
SendPacket) avant de traiter le suivant. 

Propriétés Nous avons vu précédement que pt attend de recevoir 3c + 2 acquittements de chaque message 
pour arrêter de l'envoyer, ce qui garantit que pj a reçu au moins 2c + 2 copies de ce message (dont au moins 
c + 1 réellement envoyées par pî) et donc que ce message a bien été délivré à pj si ab ^ lastjielivered. Si 
ce n'est pas le cas, l'usage du message de synchronisation nous garantit que notre protocole ne perd aucun 
message envoyé par p,. L'usage du bit alterné nous garantit l'absence de duplication après la première 
réception (si le premier message reçu est un message fantôme, celui-ci peut être la copie d'un message 
valide ultérieur, ce qui cause au pire une duplication). Le fait d'attendre de recevoir c + 1 copies de chaque 
message avant de le délivrer garantit que seul le premier message délivré peut être un message fantôme. 
Enfin, le fait qu'un message m soit délivré à pj entre le début et la fin de l'exécution de Send(in) par pi et 
que les appels à cette fonction soient bloquants pour pi implique que seul le premier message peut être ré- 
ordonné (si le premier message reçu est un message fantôme, celui-ci peut être la copie d'un message valide 
ultérieur, ce qui cause au pire un ré-ordonnancement). En conclusion, nous avons le résultat suivant^ : 
Théorème 2 S'DL est un protocole de communication (0,1,1, l)-stabilisant à travers des canaux de com- 
munication de capacité bornée mais non fiables et non FIFO. 

4 Conclusion 

Dans cet article, nous avons introduit des mesures de l'effet de fautes transitoires sur les performances 
des protocoles de communication entre voisins dans un système à passage de messages. Nous avons ensuite 
fourni un protocole optimal par rapport à ces mesures dans le cas où les canaux de communications ont une 
capacité bornée, sont non fiables et non FIFO. Toutefois, notre protocole induit un surcoût de communica- 
tion ; la question de savoir s'il est possible de conserver cette tolérance optimale aux fautes transitoires en 
baissant ce surcoût de communication de manière significative est toujours ouverte. 
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t. Une preuve complète de ce résultat peut être trouvée dans IDDPBTIOI . 



